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Abstract 

To provide high availability, many scalable data stores 
abandon traditional database functionality, often offer- 
ing operations limited to single objects (or groups of 
co-located objects) with limited consistency. However, 
many applications benefit from transactions, or larger 
units of arbitrary combinations of multiple operations on 
multiple objects. While the CAP theorem is often in- 
terpreted to preclude the availability of transactions in a 
partition-prone environment, we show that highly avail- 
able systems can provide transactional guarantees match- 
ing the majority of today's ACID databases. We propose 
Highly Available Transactions (HATs) that support many 
desirable semantic guarantees for arbitrary transactional 
sequences of read and write operations, execute with low 
latency, and remain available during partitions. 

1 Introduction 

To provide high availability and low latency, many recent 
distributed data stores eschew strongly consistent seman- 
tics. The CAP theorem stipulates that it is impossible 
simultaneously provide single-key linearizable 11431 se- 
mantics ("consistency") and available operation (avail- 
ability) in the presence of arbitrary partitions between 
servers ||40l . The implications of the CAP theorem on 
distributed system design are relatively well understood, 
and systems desiring "always on" operation must choose 
between one of several weak consistency models. 

There has been little investigation of how traditional 
ACID database semantics [42] and the CAP theorem ED) 
interact. While transactions are grounded in decades 
of database tradition ll27l |28"1 |4D . many low-latency, 
highly available stores completely eschew transactional, 
multi-object semantics under the impression that CAP 
applies to transactions, that it is impossible to provide 
highly available general-purpose transactional semantics 
in the presence of partitions. This common belief under- 
lies the NoSQL movement's rejection of ACID transac- 
tions ||39l and, when today's users require multi-object 
operations, they must often settle for operations over re- 
stricted data types (e.g., commutative and monotonic op- 
erations) ll22l 146 60 1 or with restricted semantics (e.g., 
read-only operations, entity groups) 11251 1481 |49l or in- 
stead face unavailability and high latency \29, 30 33, 34, 
|35]|44]|46]|55]|57]. 

Our goal is to understand the relationship between the 
CAP theorem and transactions. In particular, we in- 



vestigate whether it is possible to provide transactions 
that are available in partitioned environments (e.g., geo- 
replicated systems), and, by proxy, achievable with low 
latency — two increasingly common requirements 1132] 
@8] @9] EH HO). While the strongest form of ACID, seri- 
alizability, is not highly available (37), we show that the 
most common forms of transactions in today's databases 
can be made available. These ACID transactions per- 
mit weaker forms of isolation than serializability but are 
provided by default by most "ACID" and "NewSQL" 
databases, many of which do not support serializability 
at all (jj2j. The primary problem is that these isolation 
guarantees are not implemented in an available manner: 
lock-based |41|, mastered l27l . and several other dis- 
tributed transaction implementations [28] all suffer from 
unavailability. We show that this need not be the case. 

We provide a semantics for and sample implementa- 
tions of Highly Available Transactions (HATs) that are 
achievable in partitioned environments and with low la- 
tency (Sj3). These HATs match the semantics provided by 
today's databases without compromising low latency and 
"always on" operation. Most notably, first, we provide 
transactional atomicity across arbitrary data items ("A" 
in "ACID"). Second, we provide ANSI-compliant Read 
Committed and Repeatable Read isolation. Third, we 
enforce partial ordering between transactions, allowing 
us to provide several inter- and intra-transaction session 
guarantees including monotonic reads, read-your-writes, 
and causal consistency. We also discuss semantics that 
are not achievable, including recency bounds and glob- 
ally enforced correctness criteria (jj4j. 

Our primary contribution in this report is to provide 
semantics for general-purpose, read/write transactions 
achievable in a highly available environment that are use- 
fully stronger than any we have previously seen ([Q. 
In doing so, we demonstrate that we can provide the 
guarantees of today's traditional ACID databases with- 
out compromising availability, low latency, or scalabil- 
ity. This requires new, highly available implementations 
of these guarantees, but our goal here is not to provide 
high-performance algorithms or a design space explo- 
ration ($6); rather, we provide a feasibility proof. Ac- 
cordingly, HAT semantics form the basis of a new gold 
standard for highly available distributed data stores, sup- 
plying powerful transactional functionality to users who 
demand high availability and low latency. 
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2 CAP, ACID, and Availability 

The relationship between the CAP Theorem and ACID 
transactions is not always well understood. While 
linearizability ||43l and availability are provably at 
odds PDl , the ramifications for distributed, multi-object 
operations have been unclear. Here, we formally define 
the requirement for high availability, and survey ACID 
transactional semantics in theory and in practice. 

Transactions In contrast with the aforementioned sys- 
tems, we seek a model for general-purpose transactions 
that are available in the presence of partitions — HATs — 
grounded in the theory of ACID and CAP. We con- 
sider ordered collections of read and write operations, 
called transactions, that can either commit — indicating 
success — or abort — indicating failure due to the viola- 
tion of some integrity constraint over the data items (f|4]l 
or other internal error. We denote a write of value v to 
data item d as wj(v) and a read from data item d return- 
ing y as r^(v) and assume that all data items have the null 
value, _L, at database initialization. 

Availability: What and Why To begin, we first need 
to define availability. In the presence of system parti- 
tions, we could maintain availability by simply aborting 
all transactions; this guarantees a response, albeit one 
that is not very useful ll53l . On the other hand, some 
transactions may never be able to commit — for instance, 
a transaction that aborts whenever the balance of a bank 
account is negative. Accordingly, we need to distinguish 
between aborts due to transactional consistency viola- 
tions (internal aborts), such as integrity constraint vio- 
lations, which the system designer cannot prevent, and 
aborts due to system implementation and operation {ex- 
ternal aborts), which the system designer can prevent. 
We say that a system provides transactional availabil- 
ity if every transaction either eventually commits or in- 
ternally aborts. We say a system has replica availabil- 
ity [40| if every transaction can contact at least one non- 
failing replica for each data item it accesses. We say a 
system provides high availability if, given replica avail- 
ability, it provides transactional availability. 

ACID Transactions, Partitions, and Isolation Levels 

As a starting point for comparing distributed availabil- 
ity and ACID transactions, consider traditional database 
serializability ll52l and the following transactions: 

7i : W x (l) r y (a) 

T 2 :w y {\)r x (b) 
Suppose we have two servers, each acting as a replica 
for both x and y, and there is a network partition between 
the two servers. For high availability, T\ and T 2 should 
eventually commit. When they do, due to the partition, 
T\ will read a ~ _L and T 2 will read b = _L. This violates 
database serializability, because there is no serial order- 
ing of T\ , T 2 in which these reads could have occurred. 



However, with high availability, T\ and T 2 must eventu- 
ally commit, even if the partition lasts forever. 

There are several weaker isolation guarantees that are, 
in practice, more common than serializability ll20l |231 
l26l . We first define these isolation guarantees then sur- 
vey their usage. "Read Uncommitted" typically requires 
that transactions' writes be consistently serialized (pro- 
hibiting "Dirty Writes," or Adya's GO E0))Qlf we com- 
mit the following transactions, then T$ can eventually 
only see a = b = \ or a=b = 20 

7\:w,(l)w v (l) 
T 2 : w x {2) w y {2) 
T 3 : r x (a) r y (b) 

"Read Committed" requires that we do not read un- 
committed versions of data items (prohibiting "Dirty 
Writes" and "Dirty Reads," expressed as PQ ll23l or 
Gl{a,b,c} [20]). In the example below, T$ should never 
see a = 1, and, if T 2 aborts, Ti will never see a = 3: 

Ti : w x (l) w x {2) 
T 2 : w x (3) 
r 3 : r x (a) 

Finally, ANSI "Repeatable Read" requires that each 
transaction can only read one version of each data item 
that it did not produce (along with "Read Committed"). 
In the example below, T^s must see a = 1: 

T\ : w x (l) 
T 2 : w x {2) 
73 : r T (l) r x (a) 

Serializability and the Status Quo While these isola- 
tion properties do not provide serializability, they are in 
wide use. We show default and maximum isolation levels 
for many "ACID" and "NewSQL" databases in Table Q] 
Only three of 18 databases provide serializability by de- 
fault, and at least eight do not provide serializability as 
an option at all. Eight stores use Read Committed by 
default, while three "NewSOL" data stores only provide 
Read Committed isolation^ Accordingly, while HATs 
cannot provide serializability, in achieving ANSI Read 
Committed and Repeatable Read semantics, they will 
closely match several standard and widely used models. 

1 We do not consider predicate-based operations or phantoms (ij4j. 

2 When coupled with transactional atomicity (f|3), we can more mean- 
ingfully restrict the propagation of new writes (i.e., never B = 2, b = 1). 

3 We have found that many data stores mischaracterize guarantees. One 
data store with a maximum of Read Committed isolation claims to 
provide "STRONG CONSISTENCY. GUARANTEED, [sic]" ("strong 
consistency (ACID)") [2'j, while another claming "100% ACID" and 
"fully supported] ACID transactions" uses consistent read isola- 
tion 1141 . It is also common to have mislabeled isolation levels — 
serializability instead of snapshot isolation ['15']. Each reference is ac- 
companied by additional bibliographic detail, when necessary. 
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Table 1 : Default and maximum isolation levels for ACID 
and NewSQL databases as of January 2013. 

3 Highly Available Transactions 

With a clear specification of our goal of high availabil- 
ity, we present a set of semantics for HAT transactions, 
including ANSI SQL Read Committed and Repeatable 
Read isolation levels, transactional atomicity, session 
guarantees, convergence, and durability. We present al- 
gorithms solely as a proof-of-concept for high availabil- 
ity; further engineering is required to improve and eval- 
uate their performance. The HAT guarantees we present 
(and their implementations) are composable. It is possi- 
ble to choose and deploy a subset of guarantees, or, for 
maximum semantic richness, deploy all at once. 

As a baseline algorithm, clients contact available repli- 
cas for all read and write operations, and replicas store 
values to serve. Each semantic guarantee restricts which 
values can be read at any given time and, sometimes, 
when values should be cached at clients. 

ANSI SQL Isolation To begin, we consider the 
ANSI SQL Isolation levels. Traditional implementa- 
tions of these guarantees use lock-based protocols ATI , 
which are unavailable because all replicas cannot 
safely determine or modify a lock's state in a parti- 
tioned environment. Moreover, traditional distributed 
databases (regardless of lock or multi-versioned — 
MVCC — implementation) frequently employ a single 
master per data item [27], which is similarly unavailable 
under partitions, assume a lack of communication fail- 
ures, or are otherwise unavailable [28 . While we omit 
a full database literature survey, we are not aware of any 
prior highly available algorithms for these levels. 

Read Uncommitted To disallow "Dirty Write" phenom- 



ena, we need to ensure that, if two transactions write 
to the same data items, the same transaction's writes 
"win" for each data item. We need a total order on 
transactions. We can choose a unique integer ID (e.g., 
client ID and timestamp) at each transaction start and at- 
tach it to all values that we send to replicas, which can 
ensure that they only store values with increasing IDs 
(Thomas Write Rule [28]). Transaction ID generation 
is coordination-free and, if a transaction can access a 
replica, the replica can safely apply its updates and pro- 
vide a response. We will use a similar ID concept to 
order transactions in later guarantees. 

Read Committed To prevent "Dirty Read" phenomena, 
we need to ensure that transactions do not read un- 
committed data. To accomplish this, clients can buffer 
their write operations until their transactions commit. 
At transaction commit time, the client sends the last 
value written for each data item to the respective non- 
failing/partitioned replicas. This caching does not affect 
the HAT availability requirement. 

ANSI Repeatable Read In Repeatable Read, for each 
data item, transactions read at most one value that they 
did not write. Transactions can buffer read values such 
that each transaction contacts replicas at most once for 
every data item. When a transaction writes, it can over- 
write any buffered values for the data item. Like our 
"Read Committed" algorithm, this algorithm is highly 
available. 

Transactional Atomicity Transactional atomicity (the 
"A" in "ACID") is an important property^ Once some 
effects of a transaction are observed, all effects are ob- 
served: either all effects of a transaction are observed, 
or none are. For example, if T\ commits, then T2 must 
observe b = c = 1 (or later versions): 

ri:w»(l)w,(l)w z (l) 
T 2 : r x (a) r y {\) r x (b) r z (c) 

T2 can also observe a = _L or a = 1 . 

Coordinating transactional atomicity across replicas is 
challenging. For example, if, as is common [3TJ |49), we 
use a master to determine the correct set of updates to 
read, then the system will not be available when clients 
are partitioned from the master. Instead, we rely on 
decentralized background consensus to decide when to 
show new values, which can safely stall in the presence 
of partitions. Each server keeps a known good value for 
each data item d it is assigned, d goo( i and a set of pending 
updates to d, d pen( a n g. We use asynchronous consensus to 
move updates from d pen( a ng to d goo d\ all of d goo /s trans- 
actional siblings (or later values) are guaranteed present 

^Linearizability 1431 — a single object property — is often called "atom- 
icity" in distributed computing research. To disambiguate, we refer to 
this single object property as linearizability. 
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on all replicas. Without aborts, this requires only one 
synchronous round trip time (RTT). 

Writes: First, consider the case where transactions do 
not internally abort. On commit, for each written data 
item d, we send the last written value of d (d v ) with the 
transaction ID and L v , a list of all data items and values 
written in the transaction, to available replicas for d. The 
replicas immediately reply with a response to commit, 
place d v it in their respective d peru n ng , and send a receipt 
to all replicas for items in L v . Once a server receives re- 
ceipts from all replicas for all items in L v , the server sets 
dgood = d v if d v 's ID is greater than d goo dS ID. Accord- 
ingly, a new value will only appear in d gouc i when the 
other values written with d goo d (Lv) are resident on every 
respective replica (though possibly in their d penc n ng ). 

Reads: Each client maintains a vector of transaction IDs 
V, with one entry per data item {V(d)). When a client 
reads a new data item du the server returns both d\ and 
L v , and, for all data items k E L v , the client sets V(k) to 
di's ID. When a client sends a read request for item x, 
it also sends V(x), and the replica returns either x g00( j if 
it matches V(x) or occurs after V(x) in the transaction 
order or, if x g0 od is unsatisfactory, V(x) from Xp ent ji ng . If 
V (x) is empty, the server returns x goo( j. 

Aborts: If we allow internal aborts, writes require 2 
RTTs: one to check constraints and one to execute 
the above. Write propagation and update visibility are 
achieved asynchronously, as in the no-abort case. 

This implementation is entirely masterless and both 
reads and writes do not block for coordination. One key 
property is that we do not, in general, dictate when writes 
become visible (see: session guarantees, ©. Accord- 
ingly, it is highly available. 

Groups: We can optimize write visibility delay by par- 
titioning servers and clients into groups, such that each 
group contains a fully replicated set of data items and 
all clients within a group contact only the servers in the 
group. Once all transaction values are present within a 
group, values can be installed as d gooc i (as opposed to 
once they are present on all replicas). For example, in 
a multi-datacenter setting, all clients and servers within 
a datacenter may form a group. However, group-based 
atomicity is not highly available according to our defini- 
tion unless clients and servers in a group fail together, as 
is often assumed in a geo-replicated context ll48l|49l . 

Session Guarantees With HATs, we can ensure con- 
tinuity between operations via the use of session guar- 
antees [ 56 1 . We consider client-based (as opposed to 
transaction-based) sessions [58 1 but this choice does not 
affect our results. 

Read your writes requires that whenever a client reads 



a given data item after updating it, the read returns the 
updated value (or a value with a higher ID). 

Monotonic reads stipulates that a client's subsequent 
reads to a given object "never return any previous val- 
ues"; reads progress forward in a per-item ID ordering. 

Monotonic writes requires that transactions from each 
individual client be serialized (i.e., PRAM consis- 
tency 11471 ). 

We can accomplish these three requirements in two 
ways. First, clients can locally cache their reads and 
writes, updating caches when they read admissible re- 
placements from replicas [56 1. Second, clients can en- 
sure stickiness with groups ||58l (subject to the same 
groups caveat as before). For monotonic writes, clients 
should generate increasing IDs for each transaction they 
perform. Caching and ID generation are both available. 

Writes Follow Reads requires that, if a client reads 
a write originating from transaction T\ then performs 
transaction 72, then a client can only read T^'s writes if 
it can also read T\'s prior write (or overwritten values 
for 7\'s write). This requirement forms the basis for po- 
tential causality: writes follow reads obeys the "reads- 
from" relation that captures all events that influenced 
each transaction iTSD . To provide writes follow reads, 
severs (or clients) can buffer transaction writes until the 
transactions the writes depend on have been written to all 
replicas [48 1. If we consider a group model, each group 
can independently apply transactions in order via a (pos- 
sibly sharded) log-shipping approach ETl |48] |49] l60l . 

Causal consistency is the combination of all of the 
above session guarantees [36] and is also referred to as 
PL-2+ isolation [20]). We can also consider arbitrary 
application-defined partial orders, as in explicit causal- 
ity 11241 . if dependencies are specified at commit time. 

Convergence We require that, for each data item, in the 
absence of writes to the data item, reads from the item 
will eventually return the same value j58l . This con- 
vergence requirement (or eventual consistency) ensures 
that all clients will eventually observe the same database 
state and is useful because, along with the above guaran- 
tees, it requires that the system propagate values between 
replicas. We can achieve convergence via any number of 
anti-entropy protocols, where servers exchange their lat- 
est values for each item with other replicasjf] 

5 While several of our algorithms, like our implementation of causal 
consistency, are one-way convergent |50], not all are. For example, 
when coupled with user-level session guarantees, our implementation 
of transactional atomicity converges only when all replicas have ac- 
knowledged a transactions' writes, which is a much stronger conver- 
gence criterion than one-way convergence (informally, guaranteed con- 
vergence between any two replicas after they have exchanged a se- 
quence of one-way messages) and pairwise convergence. In light of 
the recent CAC impossibility result |50|, which dictates that no consis- 
tency model stronger than RTC causal consistency can be implemented 
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Durability To ensure that committed data is not lost 
due to system failures ("D" in "ACID"), we can vary the 
required number of replica writes per data item. The de- 
sired fault-tolerance of the system (say, F server-faults) 
dictates the minimum number of replica acknowledg- 
ments required for commit. We can adapt the above al- 
gorithms accordingly and the system will be unavailable 
if each client cannot contact F + 1 replicas. 

Summary We have outlined a set of semantics that 
combines well-known ACID isolation levels (ANSI SQL 
Read Committed and Repeatable Read), transactional 
atomicity, and distributed session guarantees. Each 
sample implementation can be simultaneously achieved, 
and none requires synchronous communication between 
replicas or the presence of a coordinated master for com- 
mit. Accordingly, in a partitioned environment, when 
the replica requirements for high availability are satis- 
fied, the system will provide high availability. 

4 Unsupported Semantics 

The requirement for high availability prohibits HATs 
from providing several useful guarantees. 

Recency The CAP Theorem as proven by Gilbert and 
Lynch [40 1 dictates that it is impossible to provide lin- 
earizability (informally, read the latest value of a data 
item) in a system with high replica availability. Ac- 
cordingly, HATs cannot provide bounds on data recency. 
However, systems can limit staleness of reads to the 
length of partitions, and, when the system is not par- 
titioned, it is possible to execute more coordination- 
intensive protocols than we have discussed here. Data 
recency is rarely discussed in ACID databases, as the 
serializability requirement only requires some order- 
ing on transactions, not necessarily consistent with real 
time. Additionally, it is possible to provide a notifica- 
tion of "potential data staleness" via well-known proto- 
cols often requiring heartbeats and negative acknowledg- 
ments 15411591 . 

Isolation Levels We cannot, with arbitrary transac- 
tions, prevent phantoms (Adya's P3 1201 ). which arise 
when predicate-based operations operate on inconsistent 
sets, Lost Updates (P4 ll26l ). which arise with concur- 
rent writes, read and write skew (as in snapshot iso- 
lation, which suffers A5 [26|H, or prevent Adya's G2 

in a highly available, one-way convergent system, we are particularly 
interested in further taxonomizing convergence criteria. By maintain- 
ing convergence but violating the stricter CAC one-way convergence 
requirement, HAT semantics (notably, a configuration of transactional 
atomicity with user-level causal consistency) can provide consistency 
that is strictly stronger than RTC causal consistency yet still achiev- 
able in a highly available system. (Note that alternate configurations, 
like transactional atomicity with transaction-level causal consistency 
are incomparable with RTC causal consistency.) 
6 The primary difficulties in snapshot isolation as typically defined are 
due to both concurrent writes to the same data item, which are not de- 



Anti-dependency Cycles, whose absence defines seri- 
alizability |20|. While we omit a full proof, prevent- 
ing any of these anomalies would violate availability. 
However, HATs satisfy ANSI SQL Read Committed and 
Repeatable Read Isolation (PI, P2) |23]], Adya's (non- 
predicate) PL-0, PL-1, and PL-2+ isolation fl20|, and dis- 
allow Berenson et al.'s P0, PI, and P2 anomalies l26l . 

Global Integrity Constraints As a corollary to serial- 
izability's unavailability, a highly available system can- 
not enforce arbitrary global integrity constraints (i.e., 
single-copy semantics) over data ll37l . As an example, 
uniqueness constraints on a set of values are not achiev- 
able: two clients might try to write the same value on 
different sides of a partition. This is a hmitation of 
data stores operating at any consistency level weaker 
than serializability, whether repeatable read or causal 
consistency/PL-2+. We can, however, enforce local con- 
straints, such as checking for a given value like JL. Addi- 
tionally, clients can perform constraint checking on pos- 
sibly out-of-date values (e.g., conditional modifications, 
which are often supported in weakly consistent stores 
like Riak) — useful for monotonic predicates [22 1. 

Note: Definitions Finally, different implementations of 
these semantics yield different but still compliant behav- 
ior. For example, Oracle llg uses MVCC and attempts 
to read the latest version of each data item as of the trans- 
action start time. However, the timestamps used to deter- 
mine the right version to read are not properly synchro- 
nized across replicas, leading to staleness llBTI . In con- 
trast, an unavailable lock-based implementation of ANSI 
Read Committed Isolation will read the latest value fill . 
Both of these implementations satisfy the Read Commit- 
ted specification, and neither is serializable. While we 
have noted equivalence of our semantics with the ANSI 
SQL specification ll23l and related definitions ll20l l26l . 
we believe there is future research in further categorizing 
these distinctions and refining existing database theory in 
distributed environments. This work is a step forwards. 

5 Related Work 

There has been a recent resurgence of interest in dis- 
tributed multi-object semantics, both in academia ll29l 
|3l|35llSl|46lSHlS9l|55l|57l|§a and industry l25ll30l 
[33ll . We can roughly categorize related work into two 
categories: unavailable systems with stronger semantics 
than HATs and highly available systems with weaker se- 
mantics. 

Unavailable, strongly consistent databases have a long 
tradition. As discussed in Section [3] classic ACID 
databases provide strong semantics but their lock-based 
and traditional multi-versioned implementations are un- 

tectable in a partitioned network, as well as a recency requirement 1201 . 
If we remove the recency requirement, we can provide snapshot reads 
in read/write transactions with high availability. 
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available in the presence of partitions [27. 28, 41 1. Sim- 
ilar semantics are common in recent work. Notably, 
Google's Spanner provides externally serializable trans- 
actions. While Spanner fits Google's read-mostly work- 
load well, read/write transactions use two-phase locking 
(incurring at least one round trip time over wide-area 
networks), are unavailable to clients in a non-majority 
partition, and cannot read their writes [33]. These la- 
tency and availability penalties are fundamental to pro- 
viding strong consistency. For users willing to tolerate 
these costs, Spanner, or similar strongly consistent, un- 
available systems — including Calvin lf57l . G-Store ll35l . 
Gemini g§|, Granola (34), HBase H, MDCC 04), 
Megastore __3], Orleans fl30], and Walter J53] — are a 
reasonable choice. With HATs, we seek an alternative 
that provides strong semantics without violating high 
availability or low latency. 

There are a range of data stores that provide high avail- 
ability but weaker semantics than HAT. Most recently, 
Eiger [49 1 provides an implementation of causally or- 
dered transactions. We are inspired by this work, but, 
unlike Eiger, which provides read-only and write-only 
transactions with limited availability within a datacenter 
(e.g., clusters within a datacenter are assumed lineariz- 
able and use masters to achieve transactional atomicity), 
HATs provide arbitrary multi-object transactions with 
high availability and semantics matching the guarantees 
provided by today's ACID databases. Brantner's S3 
database 11291 achieved Read Committed isolation with 
high availability and proposed the use of (unavailable) 
session guarantees. Swift ll60l provides transactions 
across commutative replicated data types (CRDTs), ob- 
viating the need for conflict resolution (like COPS [48 1). 
HATs provide a semantics that encompasses each of 
these systems, in addition to providing high availability 
for transactional visibility and ANSI isolation levels. 

6 Conclusions and Future Work 

In this paper, we have attempted to bridge the wide 
gap between distributed consistency — and the highly in- 
fluential CAP Theorem — and ACID transactions. We 
provide a set of semantics for highly available trans- 
actions, or HATs, which are achievable even in par- 
titionable systems. Our proposed HATs satisfy sev- 
eral standardized ACID atomicity, isolation, and durabil- 
ity properties; HATs can match the default (and some- 
times strongest) semantics of several existing "ACID" 
and "NewSQL" stores without compromising "always 
on" operation. While our sample algorithms serve as a 
feasibility proof for our semantics, there is substantial 
room for improvement. We are actively developing addi- 
tional theoretical results and are performing experimen- 
tal validation of HAT performance and overheads, both 
of which are forthcoming. 
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